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DETAILED ACTION 
Response to Arguments 

1 . Applicant's arguments submitted 1 8 April 2005 have been fully considered under 
all grounds and have been found persuasive on several, but not all, bases. Applicant is 
reminded that merely asserting that claims were patentable (pages 1 and 2 of remarks) 
before amendment is spurious, and in fact applicant's representative raised the point 
during the interview that in applicant's representative's opinion, prior art reference 
specifically did not teach an "application programming interface" as the instant 
application is now directed to. Examiner is not asserting that such amendments 
constitute prosecution history estoppel, but rather merely reminding applicant that 
circumstances of such amendments appear to be very much subject to interpretation. 

2. Firstly, the amendments to the claims in response to the interview with examiner 
clearly rewrite all the claims in such a way as to make them statutory subject matter, 
thus obviating ail rejections under 35 U.S.C. 101 (see amended claims and pages 4-5 of 
Remarks). Thusly, the rejection of claims 1-62 under 35 U.S.C. 101 as nonstatutory 
stands withdrawn. 

3. The various objections to the claims and specification stand withdrawn in light of 
the amendments to the specification (see Remarks pages 4-6). 

4. Applicant's asserted definition for "path" is congruent with one definition in the 
specification. Therefore, In light of Remarks page 4, applicant is hereby put on 
notice that this term will be the controlling definition for this term for the duration 
of prosecution of the instant application. This declaration constitutes prosecution 
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history estoppel for all other definitions of the term. Therefore, the rejection of daim 15 
under 35 U.S.C. 1 12, second paragraph, is withdravwi. 

5. However, with respect to the rejection of claim 20 under 35 U.S.C. 1 1 2, second 
paragraph, as indefinite, applicant's amendments and arguments raise many new 
questions and are not persuasive. Firstly, the parent independent claim, claim 1, was 
amended to overcome prior art such that the claim scope was nan-owed, such that 
"interface" was redefined by amendment to read "application programming interface". 
As such, claim 20 - when included with its parent independent claim and any 
intervening claims - now has several flaws; see below for an example. 

A broad range or limitation together with a narrow range or limitation that falls 
within the broad range or limitation (in the same claim) is considered indefinite, since 
the resulting claim does not clearly set forth the metes and bounds of the patent 
protection desired. See MPEP § 2173.05(c). Note the explanation given by the Board 
of Patent Appeals and Interferences in Ex parte Wu, 10 USPQ2d 2031, 2033 (Bd. Pat. 
App. & Inter. 1989), as to where broad language is followed by "such as" and then 
narrow language. The Board stated that this can render a claim indefinite by raising a 
question or doubt as to whether the feature introduced by such language is (a) merely 
exemplary of the remainder of the claim, and therefore not required, or (b) a required 
feature of the claims. Note also, for example, the decisions of Ex parte Steigewald, 1 31 
USPQ 74 (Bd. App. 1961); Ex parte Hall, 83 USPQ 38 (Bd. App. 1948); and Ex parte 
Hasche, 86 USPQ 481 (Bd. App. 1949). In the present instance, claim 20 recites the 
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broad recitation "interface", and the claim also recites "application program interface" in 
the parent independent claim, which is the narrower statement of the range/limitation. 

Applicant - for whatever reason, rather that be prior art or to amend for reasons 
unrelated to patentability, although examiner asserts that such was done in view of the 
prior art - has amended the parent, independent claim to have a narrow definition of the 
word interface. Applicant cannot do so and then assert that the word "interface" in a 
dependent claim has a very broad claim scope (Remarks page 5) encompassing both 
software and hardware; this is simply not permitted, as it renders the claim indefinite. 
Furthermore, it raises substantial questions regarding the enablement of this particular 
claim, as the specification is only directed to software, and claiming a hardware 
interface would seem to be substantially unsupported by the specification. 

6. The rejections to claims 4, 26, and 27 under 35 U.S.C. 112 second paragraph as 
indefinite for use of the term "context" are withdrawn in view of applicant's argument 
(see Remarks page 5). 

7. The rejections to claims 37 and 40 under 35 U.S.C. 112, second paragraph, are 
withdrawn because of applicant's amendment. 

8. The rejection to claim 39 under 35 U.S.C. 112 second paragraph stands 
withdrawn because applicant has clarified the term in question in such a way as to 
render the definite concomitant in scope with the other claims. 

9. The rejections of claims 1 , 36, and all other pending claims under 35 U.S.C. 
102(b) as anticipated by a mental process in a human being (under In re Prater) 



Application/Control Number: 10/693,633 Page 5 

Art Unit: 2672 

augmented with pencil and paper stands withdrawn in view of applicant's amendments 
that limit the claim's scope to computer implementation. 

11. As to the rejections of applicant's invention under 35 U.S.C. 103(a), all stand 
withdrawn because of applicant's amendments. With respect to applicant's arguments 
(page 7 and fonvard) several flaws exist. For example, applicant maintains under In re 
Ge/s/er that if the prior art in any material respect teaches away from the claimed 
invention, the claimed art cannot be used. This is not entirely an accurate 
characterization of recent or cun-ent opinions from the CAFC. First of all, "teaching 
away" is a very broad concept that is subject to interpretation, and each case tends to 
be different, see for example MPEP 2123, Merck & Co. v. Biocraft Laboratories, 874 
F.2d 804, 10 USPQ2d 1843 (Fed. Cir.), cert, denied, 493 U.S. 975 (1989). Simply 
because a disclosure teaches one embodiment as being less than optimal, or that 
something is at the bottom of a range, does not teach away from it. For example see 
the holding under In re Geisler (or Titanium Metals Corp. of America v. Banner, 778 
F.2d 775, 227 USPQ 773 (Fed. Cir. 1985)), where the Federal Circuit found that if 
ranges are close enough, one of ordinary skill in the art would have found it obvious to 
modify them (see MPEP 2144.05 [R-1], section I). Also, that statement made by 
applicant above is very similar to the guidance provided in MPEP 2144.05[R-1], section 
ll-A, but again, the circumstances of the individual case are the controlling factor. 

Secondly, applicant argues on page 9 of Remarks that the Office Action failed to 
establish motivation. Applicant is reminded that the addition of the API limitation 
occurred via amendment and that apparently this was done in order to clarify the 
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intended meaning of tlie claim. In re Dembiczak does not support applicant's 
conclusions here. Examiner provided other evidence and statements in support of 
motivation to combine; those will be explicitly clarified and demarcated in the recited 
rejections below. Further, the logic used in not erroneous, and applicant's 
counterexample suffers from a fatal flaw, as such statements are in fact perfectly good 
evidence one of ordinary skill in the art and are not improper under Dembiczak. For 
example, all displays to date (and in both Steele and Kim) are inherently two- 
dimensional. Three-dimensional graphics may be shown on a two-dimensional display; 
that is trivially well known in the art and has been done for years; as a matter of fact and 
law, the Kim reference does so. It is trivially well known in the art that computer 
graphics systems in the art perform both two- and three-dimensional processing, and 
Kim uses a personal computer as one embodiment, which are known to have such 
graphics cards and systems (see for example NVIDIA graphics cards, one of which is 
US 6636215 to Greene, and those from ATI). Therefore, the argument that simply 
because the graphics systems are complementary and supplementary, that this is not 
sufficient motivation is fatally flawed, given that personal computers and other 
multimedia devices that combine, support, and utilize both types of graphics are 
extremely common and have existed for over a decade, and both types of graphics are 
found on the Internet (as an example medium)(Kim), but the Internet is still mostly two- 
dimensional graphics, which proves that a system handling both would again be trivially 
obvious in the art, and thusly the counterexample of Windows and Unix is not a valid 
one for the circumstances of this case. A perfect example of this system is US 
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6,741,242 B1 to Itoh et al, where a web browser that draws both two- and three- 
dimensional graphics is taught. This system uses SVG and a three-dimensional canvas 
as recited in applicant's claims. 

After further consideration, new grounds of rejection follow below. 
Claim Rejections - 35 USC §112 

12. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctiy 
claiming the subject matter which the applicant regards as his invention. 

13. Claims 20 and 62 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. See arguments above for the details. 

However, with respect to the rejection of claim 20 under 35 U.S.C. 112, second 
paragraph, as Indefinite, applicant's amendments and arguments raise many new 
questions and are not persuasive. Firstly, the parent independent claim, claim 1 , was 
amended to overcome prior art such that the claim scope was narrowed, such that 
"interface" was redefined by amendment to read "application programming interface". 
As such, claim 20 ~ when included with its parent independent claim and any 
intervening claims - now has several flaws; see below for an example. 

A broad range or limitation together with a narrow range or limitation that falls 
within the broad range or limitation (in the same claim) is considered indefinite, since 
the resulting claim does not clearly set forth the metes and bounds of the patent 
protection desired. See MPEP § 2173.05(c). Note the explanation given by the Board 
of Patent Appeals and Interferences in Ex parte Wu, 10 USPQ2d 2031 , 2033 (Bd. Pat. 
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App. & Inter. 1989), as to where broad language is followed by "such as" and then 
narrow language. The Board stated that this can render a claim indefinite by raising a 
question or doubt as to whether the feature introduced by such language is (a) merely 
exemplary of the remainder of the claim, and therefore not required, or (b) a required 
feature of the claims. Note also, for example, the decisions of Ex parte Steigewald, 131 
USPQ 74 (Bd. App. 1961); Ex parte Hall, 83 USPQ 38 (Bd. App. 1948); and Ex parte 
Hasche, 86 USPQ 481 (Bd. App. 1949). In the present instance, claim 20 recites the 
broad recitation "interface", and the claim also recites "application program interface" in 
the parent independent claim, which is the narrower statement of the range/limitation. 

Applicant - for whatever reason, rather that be prior art or to amend for reasons 
unrelated to patentability, although examiner asserts that such was done in view of the 
prior art - has amended the parent, independent claim to have a narrow definition of the 
word interface. Applicant cannot do so and then assert that the word "interface" in a 
dependent claim has a very broad daim scope (Remarks page 5) encompassing both 
software and hardware; this is simply not pemriitted, as it renders the claim indefinite. 
Furthermore, it raises substantial questions regarding the enablement of this particular 
claim, as the specification is only directed to software, and claiming a hardware 
interface would seem to be substantially unsupported by the specification. 

As to claim 61 , it is dependent upon itself, which makes no sense, and it is 
obviously indefinite. For examination purposes, it will be treated as being dependent 
upon claim 36. 



Application/Control Number: 10/693,633 Page 9 

Art Unit: 2672 

C/a/m Rejections - 35 USC § 103 

1 4. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identjcally disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention vi/as made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in vi^iich the invention was made. 

1 5. Claims 1 -3, 1 8, 20, 28, 36, and 62 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over Itou et al (US 6,741 ,242 B1 ) in view of Kim et al and the SVG 
specification (Itou references the SVG specification in the list of cited documents on the 
patent anyway, and Itou clearly utilizes SVG as set forth below; therefore, no other 
statement for why SVG is incorporated is necessary). [Applicant did not dispute the use 
of the definition for scene graph used by examiner in the last office action]. 

16. As to claim 1, 

In a computing environment, a computer-implemented method comprising, 
-Receiving a function call via an application programming interface, the function call 
comprising markup language data; and (Kim Fig. 2 clearly shows that the system 
receives 3D data in X3D format, which is known to be In a markup language [0004- 
0008]. X3D is known to one of ordinary skill in the art to be the next generation of the 
VRML (virtual reality markup language) and to accept and be an extension of XML 
(extensible markup language). Next, the X3D browser - element 140 in Figs. 1 and 2, 
makes function call based on information that it obtains when it sends out requests for 
data: Further, see Fig. 3, where clearly the system is shown to receive user events and 
data from the user interface. Clearly, these represent function calls via an 
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interface.)(ltou teaches in 1:20-2:25 that clearly the system receives markup language 
of form similar to XML, and that the system works with a web browser, in a similar way 
as that of Kim. Further, Itou teaches the use of an API (19:1-20, which teaches the use 
of a Java AWT API and further teaches that it is well known in the art to make calls to 
graphics libraries such as OpenGL (see 19:1-2); 19:50-23, where graphics array data is 
passed to the Java AV\n" API; 22:33-55, where functions are shown to make calls to the 
API, e.g. functions are used to set or change parameters, and those requests are sent 
to the API, which therefore proves that an API is used to receive a function call; finally 
30:26-52, where it very clearly states that the scene graph provides an API that can 
make many changes to the content, which matches with the above system)(Also, note 
that Itou 1:20-2:50, 22:19-26, etc., it is noted that the three-dimensional source data can 
be VRML, and that data can also be obtained in SVG format (2:16-25)) 
-Interpreting the markup language data to cause data in a scene graph to be modified; 
and (Itou teaches in 1 :20-2:25 that clearly the system uses a scene graph. Further, Itou 
teaches the use of scene graphs and the modification of their data using markup 
language (for example, the listed use VRML in 1:20-2:50, 22:19-26, etc, where XML and 
other languages are also taught) (19:1-20, 19:50-23, 22:33-55, finally 30:26-52. where it 
very clearly states that the scene graph provides an API that can make many changes 
to the content, which matches with the above system), and Itou can receive data in SVG 
format as well (2:19-28)) (Kim [0007-0008] clearly teaches the use of a scene graph and 
that X3D requires the construction of such scene graphs from primitives. Kim further 
teaches that the user can move through a scene [0020, 0026], which clearly establishes 
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that a user is navigating and tlie scene is constantly being re-rendered, which prima 
facie requires data In the scene graph to be modified. Kim can also use MPEG-4, which 
clearly involves animation and modification of data in a scene graph.) 
-Causing a change in a display in response to the modification of data In the scene 
graph. (Kim clearly teaches In Fig. 4 that the output of the X3D system is shown on a 
client display, and changes clearly are reflected in the display [0013, 0031 -0032]. )(ltou 
clearly teaches that the scene graph is modified and that the final output is shown on a 
display within a web browser - see Figs. 1 and 2, where the Display Is shown, and see 
Fig. 8, where the web browser 3 gets data from scene graph 101 , amongst other data 
sources) 

Reference Itou thusly teaches all the limitations of the recited claim, except that 
in light of applicant's specification. It is unclear the exact extent of the term markup 
language, and it Is unclear if parsing is required, where if the term Is taken broadly Itou 
would teach all the limitations, but reference Kim Is brought In to cover possible 
deficiencies with that term. Thusly, reference Kim teaches all the limitations of the 
above claim, but does not expressly teach the modification of data in the scene graph, 
although, as set forth above, such functionality is inherent in the reference. Reference 
Itou teaches the web browser with all of the rendering mechanisms, scene graph, etc., 
as shown in for example Figures 2 and 8. Reference Kim teaches the use of client 100 
with X3D browser 110 over communication network 150 [0015, 0018, 0020]. Clearly, a 
portable device could fulfill this device (e.g. advanced PDA, cellular phone, or laptop.) 
Clearly, the references are directed to the same problem-solving area and further as set 
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forth above are analogous art. As such, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to combine the web browser 
of Itou with the X3D and graphics system of Kim, because they utilize very similar 
browsing mechanisms and both handle three-dimensional data over the web, but in 
different formats - X3D is taught by Kim to be the next generation of the VRML 
language used by Itou (see for example, element 100 in Fig. 8), and thusly it by obvious 
to modify Itou to use X3D in addition to VRML. 
17. As to claim 2, 

The method of claim 1 wherein causing data in the scene graph to be modified 
comprises causing Initialization of a new instance of a visual class. 

Reference Kim does not expressly teach this limitation, but implicitly does 
because of the use the X3D specification. This specification - and the structure of 
markup languages in general - means that when non-visible objects become visible, 
e.g. data is pulled firom the X3D stream that does so through the parser [0020, 0025- 
0026], the data in the scene graph changes as well, as with limited memory the entire 
3D world cannot be stored on the client. The same logic applies to the Itou reference, 
which teaches that SVG, VRML, etc. data is decomposed into scene graphs, see Fig. 8, 
element 101 , and 4:10-40, which clearly teaches the use of scene graphs, and again - 
whenever new visual elements enter the scene, new subgroups are instantiated, which 
prima facie (see SVG specification, section 9) are elements that compose visual 
objects, which therefore are new instances of a visual class as recited above, since a 
class as recited by applicant is comparable to the basic 'shapes' In SVG (applicant's 



Application/Control Number: 1 0/693,633 Page 1 3 

Art Unit: 2672 

specification clearly uses it -23:1-20 where applicant's invention adopts all classes and 
shapes from SVG) and thusly meets the recited limitation. Further, in Itou 29:60-30:25, 
the leaf nodes are taught to be new instances of various visible classes and other 
elements, which would require them to be new instances of 'visual classes', since the 
Itou implementation uses a Java API, and it is well known in the art in Java that all 
objects are instances of classes, and any object that would appear on the drawing 
canvas would prima facie be a 'visual object' and thus a new instance of a 'visual class*. 
Motivation and combination is taken from claim 1 . 

18. As to claim 3, 

The method of claim 2 wherein causing data in the scene graph to be modified 
comprises invoking code to associate a transform with a visual object in the scene 
graph. 

Itou teaches this limitation in for example 29:60-30:25, where it is taught that the 
group node applies transform nodes to map the spatial positions of lower nodies and 
otherwise to control the elements in the scene graph, and further that (3:40-55) two- 
dimensional objects can be transformed into three-dimensions. Such modifications 
piima facie must associate code with a suitable / desired transform (e.g. scaling, 
rotation, et cetera 1 1:55-57, where types of transforms are listed), as that is the only 
way either a hierarchy of nodes (e.g. Fig. 21) or single nodes could be scaled, 
transformed, etc., and obviously all modifications are done via markup language as 
recited in the claims. 

19. As to claim 18, 
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The method of claim 1 wherein causing data in a scene graph data structure to be 
modified comprises invol^ng a function related to transforming coordinates of a visual in 
the scene graph data structure. 

Clearly, Itou as stated above in the rejection to claim 3 teaches in 29:60-30:25 
that transform nodes are applied to transforming spatial coordinates of objects in the 
scene graph in the form of child nodes and the rest of it. Since only the primary 
reference is utilized, no separate combination or motivation is required. 

20. As to claim 20, 

The method of claim 1 wherein causing data in the scene graph be modified comprises 
invoking a function via a common interface to a visual object in the scene graph data 
structure. 

Clearly, such modifications to the scene graph are made via the Java API and 
the scene graph API itself to allow the objects to be modified as set forth in the rejection 
to claim 1 above. As such, the rejection to claim 1 is incorporated by reference. 

21. As to claim 28, 

The method of claim 1 wherein causing data in the scene graph to be modified 
comprises invoking a function to place a three-dimensional visual into the scene graph 
data structure. 

The Kim reference clearly teaches this limitation. The Kim reference clearly 
teaches scene graphs as established in the rejection to claim 1 [0007-0009]. Clearly, 
Kim teaches the use of three-dimensional data under the X3D standard specification, 
which is a form of XML [0007-0009]. Clearly, Kim teaches [0032-0034] that scene data 
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is processed and all objects have specific sets of data associated with them, for 
example [0042-0044], which clearly establishes that all objects have three-dimensional 
attributes and properties. This prima facie establishes that three-dimensional visuals 
are placed into the scene graph data structure. Clearly, the system implements the 
X3D specification in software, and, as such, it is software, which prima facie uses 
function calls. Motivation and combination is taken from claim 1 and incorporated via 
reference. Further Itou obviously (1 :30-2:45) puts three-dimensional objects in the 
scene graph (see Fig. 8, 12, 21, etc.). 

22. As to claims 36 and 62, the rejection to claim 1 is herein incorporated by 
reference in its entirety. 

[The means recited in claim 65 are those of the X3D parser of Kim and the SVG 
parser inherent in the Steele reference as set forth below, as applicant extensively 
references the SVG specification in his specification, and so the rejection on claim 36 is 
valid and binding on claim 65 without further comment.][ltou clearly teaches SVG as 
taught in the rejection to claim 1 above, which is incorporated by reference] 
In a computing environment, a computer system comprising: 

-A markup parser; (Itou 1 :40-55, 2:8-25 where it parses SVG and various means can be 
activated by said parser, one parser shown as element 12 in Fig. 2)(Kim Fig. 2, element 
142 - parser, see [0025])(SVG graphics data requires DOM objects (see SVG 
standard), which inherently requires an XML parser as part of that system, as the XML 
data has to be processed and formatted, which is what a parser by definition does - as 
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shown in Fig. 2, all compilers must parse syntax at a minimum - this is a fundamental of 
the computer art) 

-An application programming interface coupling the markup parser to a source of 
markup; and (Itou teaches in 1:20-2:25 that clearly the system receives markup 
language of form similar to XML, and that the system works with a web browser, in a 
similar way as that of Kim. Further, Itou teaches the use of an API (19:1-20, which 
teaches the use of a Java AWT API and further teaches that it is well known in the art to 
make calls to graphics libraries such as OpenGL (see 19:1-2); 19:50-23, where graphics 
array data is passed to the Java AWT API; 22:33-55, where functions are shown to 
make calls to the API, e.g. functions are used to set or change parameters, and those 
requests are sent to the API, which therefore proves that an API is used to receive a 
function call; finally 30:26-52, where it very clearly states that the scene graph provides 
an API that can make many changes to the content, which matches with the above 
system)(Also, note that Itou 1:20-2:50. 22:19-26, etc., it is noted that the three- 
dimensional source data can be VRML, and that data can also be obtained in SVG 
format (2:16-25)) (interface is coupled to XML channel in Fig. 1 through communications 
network 150 and then into the X3D browser as shown in Fig. 3, which is shown to 
receive X3D data through communications module 130 and this is exactly stated in 
[0032]) 

-A container for visual information of an object model, the markup parser converting 
markup received at the application programming interface to method calls of objects in 
the object mode to modify data in the container for visual information. (Itou must prima 
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facie modify data in the scene graph as it creates various elements in it, can spatially 
translate them and perform various operations on them as noted in the rejection to claim 
1, and in 11:1-12:67, various elements are shown as part of the markup include 11:55- 
60, where those transforms are known (see Steele as evidence that such transforms 
are well known in the art and part of S\/G)(SVG provides container objects for visual 
data, and SVG clearly teaches the use of container objects, as in section 1 .6 it clearly 
teaches the use of 'container elements', which are defined as 'An element that can have 
graphic elements and other container elements as child elements'. Clearly, the 
container object could be the head object of the tree structure shown in Itoh Fig. 21 , and 
the group node referred to therein. Further SVG is known to rnodify elements in a 
hierarchy) (Further, X3D standard provides for container objects in the definitions, see 
"Container object", section 3)(ltou clearly has group nodes as cited in Fig. 21 , and 
further in 30:50-31:38) 

-A video interface operable to interpret the visual information for display on a display. 
(Kim clearly teaches in Fig. 4 that the output of the X3D system is shown on a client 
display, and changes clearly are reflected in the display [0013, 0031-0032].)(ltou clearly 
teaches that the scene graph is modified and that the final output is shown on a display 
within a web browser - see Figs. 1 and 2, where the Display is shown, and see Fig. 8, 
where the web browser 3 gets data from scene graph 101 , amongst other data 
sources.) 

Kim [0007-0008] clearly teaches the use of a scene graph and that X3D requires 
the construction of such scene graphs from primitives. Kim further teaches that the user 
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can move through a scene [0020, 0026], which clearly establishes that a user is 
navigating and the scene is constantly being re-rendered, which prima facie requires 
data in the scene graph to be modified. Kim can also use MPEG-4, which clearly 
involves animation and modification of data in a scene graph. Itou uses SVG, and 
teaches the decomposition of graphic data into tree structures in Fig. 20, with scene 
graph 160 being turned into a scene graph tree 158. Further, Fig. 21 and 12 clearly 
illustrates what happens when the SVG animation language is transformed into two sets 
of output language data. Clearly, as the SVG standard sets forth, animation is done 
with SVG on a routine basis and the translation is shown in Fig. 6. The tree of Figs. 12 
and 21 is clearly a form of scene graph in the broad definition set forth above. Clearly, 
such a tree is a "scene graph". Thusly and prima facie obviously, any 4:48-5:15, where 
animation would cause data in a scene graph to be modified as the object was 
translated and the data structure containing locations and other information would 
changed. 

Reference Kim teaches the use of client 100 with X3D browser 110 over 
communication network 150 [0015, 0018, 0020]. Clearly, a portable device could fulfill 
this device (e.g. advanced PDA, cellular phone, or laptop.) Reference Itou thusly 
teaches all the limitations of the redted claim, except that in light of applicant's 
specification, it is unclear the exact extent of the term markup language, and it is 
unclear if parsing is required, where if the temn is taken broadly Itou would teach all the 
limitations, but reference Kim is brought in to cover possible deficiencies with that term. 
Thusly, reference Kim teaches all the limitations of the above claim, but does not 
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expressly teach the modification of data in the scene graph, although, as set forth 
above, such functionality is inherent in the reference. Reference Itou teaches the web 
browser with all of the rendering mechanisms, scene graph, etc., as shown in for 
example Figures 2 and 8. Reference Kim teaches the use of client 100 with X3D 
browser 110 over communication network 150 [0015, 0018, 0020]. Clearly, a portable 
device could fulfill this device (e.g. advanced PDA, cellular phone, or laptop.) Clearly, 
the references are directed to the same problem-solving area and further as set forth 
above are analogous art. As such, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to combine the web browser of Itou 
with the X3D and graphics system of Kim, because they utilize very similar browsing 
mechanisms and both handle three-dimensional data over the web, but in different 
formats - X3D is taught by Kim to be the next generation of the VRML language used 
by Itou (see for example, element 1 00 in Fig. 8), and thusly it by obvious to modify Itou 
to use X3D in addition to VRML. 

SVG is a markup language, therefore any SVG rendering utility would prima facie 
receive markup, and any SVG rendering program would prima facie invoke such 
functionality. 

23. Claims 4-1 7, 1 9, 21 -27, 30-35, and 37-61 are rejected under 35 U.S.C. 1 03(a) as 
unpatentable over Itou in view of Kim and SVG as applied to claim 1 , and further in view 
of Steele. 

24. As to claim 4, 
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The method of claim 1 wherein causing data in a scene graph data structure to be 
modified comprises involving code to place a drawing visual into the scene graph. 

Reference Kim does not expressly teach this limitation, but clearly teaches that 
users navigate through a virtual environment, which prima facie requires that transforms 
take place to visual objects and new visual objects be inserted (see rejections to claim 2 
and 3). Reference Itou does not expressly teach this limitation, but in 14:1 1-50 does 
teach that the system inserts two-dimensional drawing canvas commands into the 
three-dimensional drawing canvas by transforming them into three-dimensional 
commands. 

Reference Steele teaches this limitation, as for example he teaches the insertion 
of unique identifiers into media streams [0106], and further [0088] that any visual 
element or object can modified. Such modifications and insertions prima facie must 
associate code with a suitable / desired insertion as that is the only way either a 
hierarchy of nodes (e.g. Fig. 7) or single nodes could be logically Inserted. 

For the second case, if the definition of context is the data associated with a 
specific element - e.g. the details of the element, its location, color, et cetera, these 
attributes are inherent in SVG elements as set forth in the rejections above, e.g. 
sections 1 1 .1, 9.1-9.7, et cetera. Further, Steele teaches the same in Figure 7, where 
each element has certain properties that would be a drawing context, in the sense that 
each visual element has those properties associated with it [Steele 0052-0056 and 
0059-0061]. 
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As such, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to combine the SVG and graphics system of Steele and 
Itou with the X3D and graphics system of Kim as set forth above, and because Itou very 
clearly teaches the use of SVG formatting and standards and further Steele would 
extend the functionality of Itou as Steele adds the behavior-based parsing capabilities 
as shown in Figs. 3 and 5, for further control of elements - see [0052-0054]. (Further, 
note that since this is perfomried by software, prima facie 'code' that is software 
elements, would be invoked to perfonn any recited task.) 
25. As to claim 5, 

The method of claim 4 further comprising, causing drawing context to be returned, the 
drawing context providing a mechanism for rendering into the drawing visual. 

References Kim and Itou do not expressly teach this limitation, but clearly 
teaches that users navigate through a virtual environment, which prima facie requires 
that device specific infomiation regarding display information, e.g. drawing context, be 
available to the rendering engine. Reference Steele teaches this limitation, as for 
example he teaches the retrieval of device context in [0101]. Clearly, the device 
receives information based on its device context, which clearly is associated with the 
drawing context, as the two are one and the same in this case. Steele teaches 
rendering in [0007 and 001 1-0012]. The drawing context per se is incorporated into the 
data structures of Steele (see Figure 7). Reference Kim clearly teaches rendering in 
Fig. 2, element 143, "rendering means". Further, Itou teaches the use of scene graph 
data hierarchies (see Fig. 21), which dearly establishes that drawing context must exist 
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in order for that group node to know its spatial location (29:60-30:25). Motivation and 
combination is taken from claim 4 above. It further would have been obvious to modify 
the system of Kim to utilize a device specific context so as to optimize data streamed to 
that device for purposes of minimizing memory consumption (a large problem pointed 
out by Steele [0007]). ). (Further, note that since this is performed by software, prima 
fade 'code' that is software elements, would be invoked to perform any recited task.) 
26. As to claim 6, 

The method of claim 2 wherein causing data in the scene graph to be modified 
comprises invoking code to associate brush data with a visual object in the scene 
graph. 

Reference Kim does not expressly teach this limitation. References Itou and 
Steele do teach this limitation by the use of SVG graphics. Turning to the SVG (, 
section 1 1 titled 'Painting: Filling, Stroking, and Marker Symbols', specifically section 
11.1, "With SVG, you can paint (e.g. stroke or fill) with: ..." and then proceeds to list 
several. The term 'brush data' is clearly analogous to the 'paint' operation in SVG with 
comparable data. Given that SVG allows (from section 1 1 .1 ) a single color, a solid color 
(with or without opacity), a gradient, a pattern (vector or image), and custom patterns, 
clearly each visible element clearly has such data associated with it (see section 1 1 .2 in 
its entirety, 1 1.7 for specific properties, section 1 1.8 for how painting properties can be 
inherited, which prima facie justifies the position that element have intrinsic painting 
properties, i.e. brush data as set forth above. Further, note that since this is performed 
by software, prima facie 'code' that is software elements, would be invoked to perform 



Application/Control Number: 10/693,633 Page 23 

Art Unit: 2672 

any recited task, and SVG data element prima facie and inherently possess paint data 
as set forth by the SVG specification above. As such, references Itou and Steele 
intrinsically teach this limitation and the SVG standard inherently handles these paint 
limitations. Motivation and combination is further taken from claim 4 and incorporated 
by reference. 

27. As to claim 7, 

The method of claim 6 wherein the brush data comprises receiving data corresponding 
to a solid color. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teaches them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Section 1 1 .1 of the SVG specification sets 
forth that a user can paint with a solid color with opacity, thus meeting this limitation. 
Further, note that since this is performed by software, prima facie 'code' that is software 
elements, would be invoked to perform any recited task, and SVG data element prima 
facie and inherently possess paint data as set forth by the SVG specification above. As 
such, references Itou and Steele intrinsically teach this limitation. Motivation and 
combination are further taken from claim 6 above and incorporated by reference. 

28. As to claim 8, 

The method of claim 6 wherein receiving brush data comprises receiving data 
coR-esponding to a linear gradient brush and a stop collection comprising at least one 
stop. 
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References Itou, Kim, and Steele do not expressly teach these limitations; 
reference Steele teaches them intrinsically as set forth above in claim 6 and reference 
SVG clearly supports this position. Section 1 1 .1 of the SVG specification sets forth that 
a user can paint with a gradient that can be linear. Further, sections 1 1 .7. 1 and 1 1 .7.2 
of the specification sets forth that gradient stops are included in the SVG 'color- 
interpolation' property. Further, note that since this is performed by software, prima 
facie 'code' that is software elements, would be invoked to perform any recited task, and 
SVG data element prima fade and inherently possess paint data as set forth by the 
SVG specification above. As such, references Itou and Steele intrinsically teach this 
limitation; motivation and combination is taken from 6 and incorporated via reference. 
29. As to claim 9, 

The method of claim 6 wherein receiving brush data comprises receiving data 
corresponding a radial gradient brush. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teaches them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Section 11.1 of the SVG specification sets 
forth that a user can paint with a gradient that can be radial and also see sections 
1 1 .7.1 and 1 1 .7.2 for more detail, thus meeting this limitation. Further, note that since 
this is performed by software, prima facie 'code' that is software elements, would be 
invoked to perform any recited task, and SVG data element prima facie and inherently 
possess paint data as set forth by the SVG specification above. As such, references 
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Itou and Steele intrinsically teach this limitation; motivation and combination is 
incorporated from claim 6. 

30. As to claim 10, 

The method of claim 6 wherein receiving brush data comprises receiving data 
corresponding to an image. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teach them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Section 1 1 .1 of the SVG specification sets 
forth that a user can paint with an image with further details provided in section 1 1 .7.5 
under the 'image-rendering' property. Further, note that since this is performed by 
software, prima facie 'code' that is software elements, would be invoked to perform any 
recited task, and SVG data element prima facie and inherently possess paint data as 
set forth by the SVG specification above. Motivation and combination is incorporated 
from claim 6. 

31 . As to claims 1 1 and 56, 

The method of claim 10 further comprising, receiving markup corresponding to an 
image effect to apply to the image. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teaches them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Section 14.4 of the SVG specification sets 
forth that a user can use any image as an opacity mask, thus meeting this limitation, 
given that alpha blending Is prima facie an image effect. Further, note that since this is 



Application/Control Number: 10/693,633 Page 26 

Art Unit: 2672 

performed by software, prima facie 'code' that is software elements, would be invoked 
to perform any recited task, and SVG data element prima facie and inherently possess 
paint data as set forth by the SVG specification above, and SVG is inherently a markup 
language, so the rendering portion of Steele would receive such information (the 
rendering functionality is inherent in SVG - see section 11. 7, 14.4, et cetera). 
Motivation and combination is also incorporated from claim 6. 
32. As to claim 12, 

The method of claim 1 further comprising, receiving markup corresponding to pen data 
that defines an outline of a shape. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teach them intrinsically as because of their use of SVG as 
set forth above in the rejections to claims 4 and 5 and reference SVG clearly supports 
this position. The term 'pen data' used by applicant above is comparable or analogous 
to any set of data defining the outline of a shape, including SVG 'path' data. Section 
1 1 .3 of the SVG specification sets forth that a user can fill a path that would correspond 
to the outline of shape with multiple Illustrations provided for this under the 'nonzero' 
and 'even odd' subheadings - see details on paths - with further details provided in 
section 1 1 .3 and 1 1 .4 (the individual strokes that create these effects. SVG is a markup 
language, therefore any SVG rendering utility would prima facie receive markup. As 
such, references Itou and Steele intrinsically teach this limitation. Motivation for 
combining Itou, Kim, and SVG is taken from the rejection to claim 1 . Motivation for 
adding Steele is taken from the rejections to claims 4 and 5. 
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33. As to claim 13, 

The method of claim 1 wherein the markup corresponds to a shape class comprising at 
least one of the set containing rectangle, polyline, polygon, path, line and ellipse 
shapes. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teach them intrinsically as set forth above in claim 1 and 
reference SVG clearly supports this position. The SVG specification sets forth classes 
of shapes in section 9.1 , where all six of the recited shapes (rectangle, polygon, path, 
line, polyline, and ellipse) are set forth. Further, the SVG view in Steele decomposes 
SVG instructions into scene graphs containing basic SVG shapes as above [Steele 
0052], where 'Visual Elements' include Shape classes. SVG is a markup language, 
therefore any SVG rendering utility would prima facie receive markup. As such, 
references Itou and Steele intrinsically teach this limitation. Motivation for combining 
Itou, Kim, and SVG is taken from the rejection to claim 1 . Motivation for adding Steele 
is taken from the rejections to claims 4 and 5. 

34. As to claim 14, 

The method of claim 1 wherein causing data in the scene graph to be modified 
comprises invoking a geometry-related function to represent a rectangle in the scene 
graph data structure. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teach them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. The SVG specification cleariy shows in 



Application/Control Number: 10/693,633 Page 28 

Art Unit: 2672 

section 9.1 that rectangles are a basic shape, and further that in 9.2 under Example 
rect02 that such rectangles can have rounded corners, and code is provided that 
implements such. Also, the 'Rect' class inherently has geometry-related functions as 
set forth in the beginning to section 9.2. SVG is a markup language, therefore any SVG 
rendering utility would prima facie receive markup. As such, reference Steele shows a 
rectangle 715 in the scene graph in Figure 7 that intrinsically teaches this limitation. As 
such, references Itou and Steele intrinsically teach this limitation. Motivation for 
combining Itou, Kim, and SVG is taken from the rejection to claim 1 . Motivation for 
adding Steele is taken from the rejections to claims 4 and 5. Also, said element can be 
animated under SVG section 19.2. Steele clearly teaches data modification in [0061] as 
set forth above. 
35. As to claim 15, 

The method of claim 1 wherein causing data in the scene graph to be modified 
comprises invoking a geometry-related function to represent a path in the scene graph 
data structure. 

References Kim and Steele do not expressly teach these limitations; reference 
Steele teaches them intrinsically as set forth above in claim 6 and reference SVG 
clearly supports this position. Further, Steele Fig. 6 shows an animation where path 
information is extracted into element 620, and listed in Fig. 7 (see Steele 0050 and 
0079]. Further, the SVG specification sets forth path data in section 9.1 as existing and 
how a 'path' can define a shape or similar. Both meanings are covered herein. Steele 
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clearly teaches data modification in [0061] as set forth above. Itou teaches a path 
element in 11:15-18. 

SVG is a markup language, therefore any SVG rendering utility would prima fade 
receive markup, and any SVG rendering program would prima facie invoke such 
functionality. As such, references Itou and Steele intrinsically teach this limitation. As 
such, references Itou and Steele intrinsically teach this limitation. Motivation for 
combining Itou, Kim, and SVG is taken from the rejection to claim 1. Motivation for 
adding Steele is taken from the rejections to claims 4 and 5. 
36. As to claim 16, 

The method of claim 1 wherein causing data in the scene graph to be modified 
comprises invoking a geometry-related function to represent a line in the scene graph 
data structure. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teach them Intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Further, Steele Fig. 6 shows an animation 
where path infonnation is extracted into element 620, and listed in Fig. 7 [see Steele 
0050 and 0079]. A line element can be animated under SVG section 19.2, which is 
obviously geometric. Line elements are set forth in SVG section 9.5, and their 
geometric functions. Steele clearly teaches data modification in [0061] as set forth 
above. 

SVG is a markup language, therefore any SVG rendering utility would prima facie 
receive markup, and any SVG rendering program would prima facie invoke such 
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functionality, and the scene graph shown in Figure 7 could clearly include lines since 
they are Visual Elements [Steele 0060-0061. which supports animation, et cetera]. As 
such, references Itou and Steele intrinsically teach this limitation. Motivation for 
combining Itou, Kim, and SVG is taken from the rejection to claim 1. Motivation for 
adding Steele is taken from the rejections to claims 4 and 5. 
37. As to claim 17, 

The method of claim 1 wherein the markup is related to hit-testing a visual In the scene 
graph data structure. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Steele and Itou teach them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Clearly, Kim teaches three-dimensional 
navigation in Figure 4 - that is, navigation using a Ul through a two-dimensional view- 
port of a three-dimensional environment, which is what any display normally shows. 
Therefore, given that a portable computer could dearly be used, the user would clearly 
be interacting with the display. As such, hit testing would be required for user 
interactivity, as could the system of Steele under the same rationale. The SVG 
specification sets forth hit testing in section 16.6 (the two paragraphs right at the end of 
the section) where hit testing (namely, hit detection) is taught, specifically testing text for 
character or cell hits and testing visual elements for hits in their entirety, and such 
information is clearly communicated in markup language - see section 16.2 for event 
types and elements transmitted in markup, for example. Steele clearly teaches data 
modification in [0061] as set forth above. 
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SVG is a markup language, therefore any SVG rendering utility would prima facie 
receive markup, and any SVG rendering program would prima facie invoke such 
functionality. As such, references Itou and Steele intrinsically teach this limitation. 
Motivation for combining Itou, Kim, and SVG is taken from the rejection to claim 1 . 
Motivation for adding Steele is taken from the rejections to claims 4 and 5. 

38. As to claim 19, 

The method of claim 1 wherein the markup is related to calculating a bounding box of a 
visual in the scene graph data structure. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teach them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Bounding box calculations are taught in 
section 7.1 and detailed in section 7.11 where they are calculated. Steele clearly 
teaches data modification in [0061] as set forth above. In Steele, the scene graph 
shown in Figure 7 could clearly include lines since they are Visual Elements [Steele 
0060-0061 , which supports animation, et cetera and would logically include bounding 
boxes]. As such, references Itou and Steele intrinsically teach this limitation. 
Motivation for combining Itou, Kim, and SVG is taken from the rejection to claim 1 . 
Motivation for adding Steele is taken firom the rejections to claims 4 and 5. 

39. As to claim 21, 

The method of claim 1 further comprising invoking a visual manager to render a tree of 
at least one visual object to a rendering target. 
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References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teach them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Further, Steele Fig. 6 shows an animation 
where path information is extracted into element 620, and listed in Fig. 7 [see Steele 
0050 and 0079] as trees. Further, Itou teaches in Fig. 21 the use of trees as set forth 
there, and teaches manager objects in 2:50-67. SVG teaches that all implementations 
must implement a rendering model as set forth in 3.1 and so forth, and scene graphs 
are known to directed acyclic, i.e. trees. Clearly, this model is implemented through the 
DOM interfaces set forth in section 4, and each element has its own element 
information that controls rendering aspects. Steele cleariy teaches data modification in 
[0061] as set forth above. It is prima facie obvious that a 'visual manager" of some form 
must exist in order to handle formatting issues and precedence in rendering, and Steele 
teaches such a manager in [0075-0076. Clearly the rendering information each visual 
element [Steele 0056-0061] is sufficient such that it is its own 'rendering target' as set 
forth above. It would have been obvious to one of ordinary skill in the art to add a 
manager if necessary to determine the precedence of item rendering with respect to the 
tree. As such, references Itou and Steele intrinsically teach this limitation. Motivation 
for combining Itou, Kim, and SVG is taken from the rejection to claim 1. Motivation for 
adding Steele is taken from the rejections to claims 4 and 5. 
40. As to claim 22, 
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The method of claim 1 wherein causing data in the scene graph to be modified 
comprises invoking a function to place a container object in the scene graph data 
structure, the contained object configured to contain at least one visual object. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teaches them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Further, Steele Fig. 7 shows a tree 
derived firom an animation is shown - Figure 6 [see Steele 0050 and 0079]. SVG 
clearly teaches the use of container objects, as in section 1 .6 it cleariy teaches the use 
of 'container elements', which are defined as 'An element that can have graphic 
elements and other container elements as child elements'. Steele clearly teaches data 
modification in [0061] as set forth above. Clearly, the container object could be the 
head object of the tree structure shown in Steele Fig. 7 or the group node of Itou, shown 
as the head node in Fig. 21 . As such, references Itou and Steele intrinsically teach this 
limitation. Motivation for combining Itou, Kim, and SVG is taken from the rejection to 
claim 1 . Motivation for adding Steele is taken from the rejections to claims 4 and 5. 
41 . As to claim 23, 

The method of claim 1 wherein causing data in the scene graph to be modified 
comprises invoking a function to place image data into the scene graph data structure. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teaches them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Clearty, visual elements can be covered 
by or tiled with images as established in SVG section 11.1, where SVG teaches: "...can 
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paint (i.e. fill or stroke) with: ...a pattern (vector or Image, possibly tiled) ..." which 
clearly establishes this, with more detail in section 1 1 .7.5 and 11.12. As such, 
references Itou and Steele intrinsically teach this limitation. Motivation for combining 
Itou, Kim, and SVG is taken from the rejection to claim 1 . Motivation for adding Steele 
is taken from the rejections to claims 4 and 5. 

42. As to claim 24, 

The method of claim 23 wherein causing data In the scene graph to be modified 
comprises invoking a function to place an image effect object into the scene graph data 
structure that is associated with the image data. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teaches them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Section 14.4 of the SVG specification sets 
forth that a user can use any image as an opacity mask for any visual element, thus 
meeting this limitation, given that alpha blending is prima facie an image effect. Steele 
clearly teaches data modification in [0061] as set forth above. As such, references Itou 
and Steele intrinsically teach this limitation. Motivation for combining Itou, Kim, and 
SVG is taken from the rejection to claim 1 . Motivation for adding Steele is taken from 
the rejections to claims 4 and 5. 

43. As to claim 25, 

The method of claim 1 wherein causing data in the scene graph to be modified 
comprises invoking a function to place data corresponding to text into the scene graph 
data structure. 
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References Itou, Kim, and Steele do not expressly teach these limitations; 
references Itou and Steele teach them intrinsically as set forth above in claim 6 and 
reference SVG clearly supports this position. Section 10.1 of the SVG spedfication sets 
forth the use of a 'text' element, and Steele teaches the inclusion of text element 725 in 
the data tree shown in Fig. 7. Steele clearly teaches data modification in [0061] as set 
forth above. Obviously, anything inserted into the tree of Itou (Fig. 21) would clearly 
place text in the scene. As such, references Itou and Steele intrinsically teach this 
limitation. Motivation for combining Itou, Kim, and SVG is taken from the rejection to 
claim 1 . Motivation for adding Steele is taken from the rejections to claims 4 and 5. 
44. As to claim 26, 

The method of claim 1 wherein causing data in the scene graph to be modified 
comprises invoking a function to provide a drawing context iri response to the function 

call. 

Reference Kim does not expressly teach this limitation, but clearly teaches that 
users navigate through a virtual environment, which prima facie requires that device 
specific information regarding display information, e.g. drawing context, be available to 
the rendering engine. Reference Steele teaches this limitation, as for example he 
teaches the retrieval of device context in [0101]. Clearly, the device receives 
information based on its device context, which clearly is associated with the drawing 
context, as the two are one and the same in this case. For the second case, if the 
definition of context is the data associated with a specific element - e.g. the details of 
the element, its location, color, et cetera, these attributes are inherent in SVG elements 
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as set forth in the rejections above, e.g. sections 11.1, 9.1-9.7, et cetera. Further, 
Steele teaches the same in Figure 7, where each element has certain properties that 
would be a drawing context, in the sense that each visual element has those properties 
associated with it [Steele 0052-0056 and 0059-0061]. Steele clearly teaches data 
modification in [0061] as set forth above. Itou does not expressly teach this limitation. 

SVG is a markup language, therefore any SVG rendering utility would prima facie 
receive markup, and any SVG rendering program would prima fade invoke such 
functionality. SVG is also a subset of XML, and SVG teaches metadata use in section 
21.1. As such, references Itou and Steele intrinsically teach this limitation. Motivation 
for combining Itou, Kim, and SVG is taken from the rejection to claim 1. Motivation for 
adding Steele is taken from the rejections to claims 4 and 5. 

It further would have been obvious to modify the system of Kim to utilize a device 
specific context so as to optimize data streamed to that device for purposes of 
minimizing memory consumption (a large problem pointed out by Steele [0007]), and 
the SVG DOM interfaces in section 4.1-4.4 (SVG specification) clearly provide methods 
for retrieving drawing information, which would be that context. 
45. As to claim 27, 

The method of claim 26 wherein the function call corresponds to a retained visual, and 
further comprising, calling back to have the drawing context of the retained visual 
returned to the scene graph data structure. 

References Itou, Kim, and Steele do not expressly teach these limitations; 
references Steele and Itou teach them intrinsically as set forth above in claim 6 and 
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reference SVG clearly supports this position. Section 1 1 .1 of the SVG specification 
clearly sets forth that all elements (as well as 3.1 and 4.2) have properties associated 
with them. The system of Steele clearly caches visuals during processing - see [0083], 
and it would be obvious that such data would be pulled from the cache to find out the 
state and properties of a visual element. Steele clearly teaches data modification in 
[0061] as set forth above. Further, it would be obvious to one of ordinary skill to so 
modify the Kim reference to cache the visuals so that they would be retained and that 
data would be pulled from the cache as set forth above, and as the Steele reference 
sets forth to have it pulled from there during data processing, including that of data trees 
like unto the one in Figure 7, as in [0100 Steele]. As such, references Itou and Steele 
intrinsically teach this limitation. Motivation for combining Itou, Kim, and SVG is taken 
from the rejection to claim 1. Motivation for adding Steele is taken from the rejections to 
claims 4 and 5. 
46. As to claim 30, 

The method of claim 1 wherein causing data in the scene graph to be modified 
comprises invoking a function to place animation data into the scene graph data 
structure. 

References Kim does not expressly teach this limitation, while reference Steele 
does teach it. Steele in Figs. 6 and 9 shows animated elements [0041] and in Fig. 7 
shows that each subgroup is shifted a certain amount with x and y coordinates given. 
Steele [0050, 0052] for example provides that such animation takes place, and the SVG 
standard in 19.1 - 19.5 clearly sets forth how each element can have animation 



Application/Control Number: 10/693,633 Page 38 

Art Unit: 2672 

associated with it, which clearly is placed into the scene graph of Fig. 7. Therefore, 
clearly animation data is put into the tree of Fig. 7 Steele, which is clearly a scene graph 
by every known definition of the temn, and a sample SVG XML program is provided in 
the second page of Fig. 9. Motivation for combining Itou, Kim, and SVG is taken from 
the rejection to claim 1 . Motivation for adding Steele is taken from the rejections to 
claims 4 and 5. 
47. As to claim 31 , 

The method of claim 30 further comprising communicating timeline information 
corresponding to the animation data to a composition engine. 

References Steele and Itou do not expressly teach this limitation - reference Kim 
does teach rendering (143) and scene processing (144) means in Fig. 2, which clearly 
can perform compositing (since the system does 3D rendering), while reference Steele 
does teach the animation limitation. Steele dearly establishes in [0051-0054] and Figs. 
6 and 9 that animation takes place through the SVG standard. Section 19.2 of SVG 
sets forth how this takes place, and at the bottom three paragraphs of section 19.2.2 it 
clearly states that animation has a document start and document end, and further in the 
second to last paragraph that the SVG system indicates the timeline position of 
document fragments being animated. Further, according to SVG 19.2.2 the animation 
is by document fragment and object path, which cleariy are passed to the system is 
specified in, for example, the second page of Fig. 9 in the SVG XML program. Clearly, 
the system of Steele performs compositing and rendering [0007, 001 1-0012], as does 
Kim. Finally, reference SVG teaches that it supports compositing (section 14.2.1 ), and 
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the X3D specification supports compositing (6.2.3 for example). The composition 
engine would be, for example, elements 143, 144, and 147 of Fig. 2 of Kim. Motivation 
for combining Itou, Kim, and SVG is taken from the rejection to claim 1 . Motivation for 
adding Steele is taken from the rejections to claims 4 and 5. 
48. As to claim 32, 

The method of claim 31 wherein the composition engine interpolates graphics data 
based on the timeline to animate an output corresponding to an object in the scene 
graph data structure. 

References Itou and Kim do not expressly teach this limitation, while reference 
Steele does teach it. Steele in Figs. 6 and 9 shows animated elements [0041] and in 
Fig. 8, clearly during an animation the actions are shown, where the system in steps 
835, 840, and 845 performs interpolation for nodes shown in the tree in Fig. 7. Clearly 
interpolation takes place during animation [0072, 0077-0079] which performs 
interpolation during the animation process as set forth in the SVG standard, and prima 
facie the output would only be objects in the scene graph, and they would prima facie 
be based on the timeline as set forth in the rejection to claim 31 above. 

SVG is a markup language, therefore any SVG rendering utility would prima facie 
receive markup, and any SVG rendering program would prima facie invoke such 
functionality. As such, reference Steele intrinsically teaches this limitation and it would 
have been obvious to one having ordinary skill in the art at the time the invention was 
made to combine the X3D and graphics system of Steele with the SVG and graphics 
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system of Kim as set forth above and the SVG standard specification. (Please see also 
rejection to claim 1 for additional motivation). 
49. As to claim 33, 

The method of claim 32 wherein the composition engine is at a low-level with respect to 
the scene graph. 

References Itou and Kim do not expressly teach this limitation, while reference 
Steele does teach It. Steele In Fig. 15 shows that various programs, including the 
operating system, are on the flash memory, which in [0136] Is specified to contain all the 
low-level programs of the operating system - graphics is low-level functionality. Since 
there Is no specific graphics unit, all graphics operations and compositing are done by 
the operating system in the microprocessor, which prima facie means that in that 
embodiment, such graphics are done at a low-level, that is the rendering is done by the 
operating system at a low level. The scene graph is high-level in that it is embodied in 
RAM and is held as an abstraction - this Is a function of the SVG standard that keeps 
tree nodes and container nodes as abstract as possible, therefore the embodiment in 
Fig. 18 must do the same. In any case, low-level composition means that it would be 
done by hardware that is much faster than software. As such, it would be obvious to 
modify the device of Kim and Steele to use low-level rendering, and in any case Steele 
has the rendering means set forth in the rejection to claim 32 above, which is phma 
facie entirely hardware. 

SVG is a markup language, therefore any SVG rendering utility would prima facie 
receive markup, and any SVG rendering program would prima facie invoke such 
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functionality. As such, reference Steele intrinsically teaches this limitation and it would 
have been obvious to one having ordinary skill in the art at the time the invention was 
made to combine the X3D and graphics system of Steele with the SVG and graphics 
system of Kim as set forth above and the SVG standard specification such that 
rendering would be low-level. (Please see also rejection to claim 1 for additional 
motivation). Motivation for combining Itou, Kim, and SVG is taken from the rejection to 
claim 1 . Motivation for adding Steele is taken from the rejections to claims 4 and 5. 

50. As to claims 34 and 55, 

The method of claim 1 wherein causing data in the scene graph to be modified 
comprises invoking a function to place an object corresponding to audio and/or video 
data into the scene graph data structure. 

Reference Kim does not expressly teach this limitation, while references Itou and 
Steele do teach it. Itou teaches this limitation in Fig. 5. Steele in Figs. 8 shows audio 
elements 820 and 830 in the animation execution and in Fig. 7 a scene graph data 
structure (a tree). Steele [0050, 0052] for example provides that such animation takes 
place, and the SVG standard in 6.18 clearly sets forth aural style sheets, that are audio 
data that each element can have animation associated with it, which clearly is placed 
into the scene graph of Fig. 7. Also, by definition, SVG animations would be video. 
Motivation for combining Itou, Kim, and SVG is taken from the rejection to claim 1 . 
Motivation for adding Steele is taken from the rejections to claims 4 and 5. 

51. As to claim 35, 
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The method of claim 1 wherein causing data in the scene graph to be modified 
comprises changing a mutable value of an object in the scene graph data structure. 

References Kim does not expressly teach this limitation, while reference Steele 
does teach it. Steele teaches in [0014] that one embodiment of his invention changes 
the visual graph in accordance to changes of the sequence graph, where the visual 
graph is comparable to the "scene graph" of applicant and mutable values (e.g. position) 
of elements In the tree are shifted as per Steele [0052-0057]. Therefore, the limitation is 
met, and it would have been obvious to modify it so that it in fact change mutable values 
on the tree if applicant feels that this Is not an adequate embodiment of this particular 
limitation. Motivation for combining Itou, Kim, and SVG is taken from the rejection to 
claim 1 . Motivation for adding Steele is taken from the rejections to claims 4 and 5. 
52. As to claim 37, 

The system of claim 36 wherein the markup is converted to a method call to place a tree 
of visual objects into the scene graph data structure. 

References Kim does not expressly teach this limitation, while reference Steele 
does teach it. Further, Steele Fig. 6 shows an animation where path information is 
extracted into element 620, and listed in Fig. 7 [see Steele 0050 and 0079] as trees. 
SVG teaches that all implementations must implement a rendering model as set forth in 
3.1 and so forth, and scene graphs are known to directed acyclic, i.e. trees. Clearly, ' 
Steele [0064] teaches that the visual graph is changed according to the addition or 
alteration of elements in the sequence graph, which clearly would happen with the 
insertion of new visible objects into the tree shown in Fig. 7, i.e. during animation when 
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new elements were being shown. It would have been obvious to modify the system of 
Steele to so perform the recited task. Motivation for combining Itou, Kim, and SVG is 
taken from the rejection to claim 36. Motivation for adding Steele is taken from the 
rejections to claims 4 and 5. 
53. As to claim 38, . 

The system of claim 36 wherein the markup is converted to a method call to arrange a 
tree of visual objects in the scene graph data structure. 

References Kim and Itou do not expressly teach this limitation, while reference 
Steele does teach it. Further, Steele Fig. 6 shows an animation where information is 
extracted and separated into specific elements, and shown / listed in Figs. 7 and 8 [see 
Steele 0050 and 0079] as trees. SVG teaches that all implementations must implement 
a rendering model as set forth in 3.1 and so forth, and scene graphs are known to 
directed acyclic, i.e. trees. Clearly, Steele [0064] teaches that the visual graph is 
changed according to the addition or alteration of elements in the sequence graph, 
which clearly would happen with the insertion of new visible objects into the tree shown 
in Fig. 7, i.e. during animation when new elements were being shown. Reference Itou 
implicitly teaches this with its use of tree structures and the fact that any visual elements 
can make function calls as set forth above. 

Specifically, the arrangement of a tree in the scene graph data structure again 
would be dependent on the insertion of items into the visual tree, and obviously given 
that Steele and SVG teach container objects as taught in the rejection to claim 36 
above, the insertion of a container object would prima facie cause the insertion of a tree. 
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and arranging a tree in the scene graph would qualify as "altering" elements within the 
system of Steele and falls within [0064]. 

It would have been obvious to modify the systems of Kim and Itou in light of 
Steele to so perform the recited task. SVG is a markup language, therefore any SVG 
rendering utility would prima fade receive markup, and any SVG rendering program 
would prima facie invoke such functionality and perform the recited conversion. 
Motivation for combining Itou, Kim, and SVG is taken from the rejection to claim 36. 
Motivation for adding Steele is taken from the rejections to claims 4 and 5. 
54. As to claim 39, 

The system of claim 37 wherein the markup is converted to a method call to place a 
visual collection object into the scene graph data structure. 

References Kim and Itou do not expressly teach this limitation, while reference 
Steele does teach it. Reference Itou teaches it implicitly since Itou generates tree 
objects (2:50-67, Figs. 12 and 21). Further, Steele Fig. 6 shows an animation where 
information is extracted and separated into specific elements, and shown / listed in Figs. 
7 and 8 [see Steele 0050 and 0079] as trees. SVG teaches that all implementations 
must implement a rendering model as set forth in 3.1 and so forth, and scene graphs 
are known to directed acyclic, i.e. trees. Clearly, Steele [0064] teaches that the visual 
graph is changed according to the addition or alteration of elements in the sequence 
graph, which clearly would happen with the insertion of new visible objects into the tree 
shown in Fig. 7, i.e. during animation when new elements were being shown. A 
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collection object would clearly encompass a container object containing a tree of visual 
objects; examiner is interpreting the definition in this way. 

Specifically, the arrangement of a tree in the scene graph data structure again 
would be dependent on the insertion of items into the visual tree, and obviously given 
that Steele and SVG teach container objects as taught in the rejection to claim 36 
above, the insertion of a container object would prima facie cause the insertion of a tree, 
and arranging a tree in the scene graph would qualify as "altering" elements within the 
system of Steele and falls within [0064]. 

It would have been obvious to modify the system of Kim in light of Steele and Itou 
to so perform the recited task. Motivation for combining Itou, Kim, and SVG is taken 
from the rejection to claim 36. Motivation for adding Steele is taken from the rejections 
to claims 4 and 5. 
55. As to claim 40, 

The system of claim 36 wherein the markup is converted to a method call to place a 
visual object into the scene graph data structure. 

Reference Kim does not expressly teach this limitation, but clearly teaches that 
users navigate through a virtual environment, which prima facie requires that transforms 
take place to visual objects and new visual objects be inserted (see rejections to claim 2 
and 3). Reference Steele teaches this limitation, as for example he teaches the 
insertion of unique identifiers into media streams [0106], and further [0088] that any 
visual element or object can modified. Such modifications and insertions prima facie 
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must associate code with a suitable / desired insertion as that is the only way either a 
hierarchy of nodes (e.g. Fig. 7) or single nodes could be logically inserted. 

For the second case, if the definition of context is the data associated with a 
specific element - e.g. the details of the element, its location, color, et cetera, these 
attributes are inherent in SVG elements as set forth in the rejections above, e.g. 
sections 1 1 . 1 , 9. 1 -9.7, et cetera. Further, Steele teaches the same in Figure 7, where 
each element has certain properties that would be a drawing context, in the sense that 
each visual element has those properties associated with it [Steele 0052-0056 and 
0059-0061]. Motivation for combining Itou, Kim, and SVG is taken from the rejection to 
claim 36. Motivation for adding Steele is taken from the rejections to claims 4 and 5. 
(Further, note that since this is performed by software, prima facie 'code' that is 
software elements, would be invoked to perform any recited task.) 
56. As to claim 41, 

The system of claim 40 wherein the markup is converted to a method call to associate a 
brush with the visual object. 

This claim is a substantial duplicate of claim 6. The only difference is that the 
markup is converted to a method call to perform the recited action, whereas claim 6 
merely 'invokes code' to perform the recited task, and as such would a trivial variation of 
ordinary skill in the art. The rejection to claim 6 is herein incorporated by reference with 
the motivation and combination. The SVG standard is referenced there so there is no 
difference in the reference hierarchy and it would have been trivially obvious to combine 
as set forth because the SVG specification is extensively cited by and key to the Steele 
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reference. Motivation for combining Itou, Kim, and SVG is taken from the rejection to 
claim 36. Motivation for adding Steele is taken from the rejections to claims 4 and 5. 
57. As to claim 42, 

The system of claim 40 wherein the markup is converted to a method call to associate a 
geometry with the visual object. 

References Kim, Itou, and Steele do not expressly teach these limitations; 
references Steele and Itou teach them intrinsically as set forth above in the rejection to 
claim 36 and reference SVG clearly supports this position. The SVG specification sets 
forth classes of shapes in section 9.1 , where all six of the recited shapes (rectangle, 
polygon, path, line, polyline, and ellipse) are set forth. Further, the SVG view In Steele 
decomposes SVG instructions into scene graphs containing basic SVG shapes as 
above [Steele 0052], where 'Visual Elements' include Shape classes. SVG is a markup 
language, therefore any SVG rendering utility would phma facie receive markup. 
Secondarily, the association of a geometry with a visual object would be intrinsic to the 
existence of such an object. However, SVG in section 1 1.4 sets forth different shapes 
of strokes and the same in 1 1 .6 for markers. Therefore, it would have been obvious to 
one of ordinary skill in the art to modify the Kim reference in light of Steele to be able to 
change the type of geometry associated with a visual element in accordance with the 
teachings of SVG 1 1 .4 and 1 1 .6, which meets the above-recited limitations. 

As such, references Steele and Itou intrinsically teaches this limitation and it 
would have been obvious to one having ordinary skill in the art at the time the invention 
was made to combine the X3D and graphics system of Steele with the SVG and 
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graphics system of Kim as set forth above and the SVG standard specification. (Please 
see also rejection to claim 36 for additional motivation). Motivation for combining Itou, 
Kim, and SVG is taken from the rejection to claim 36. Motivation for adding Steele is 
taken from the rejections to claims 4 and 5. 

58. As to claim 43, 

The system of claim 42 wherein the geometry comprises at least one of a set containing 
an ellipse geometry, a rectangle geometry, a line geometry and a path geometry. 

This claim is a substantial duplicate of claim 1 3. Further, the term 'geometry' 
used here is analogous to the 'shape' reference in claim 1 3. The only difference is that 
the markup is converted to a method call to perform the recited action, whereas claim 
13 merely 'invokes code' to perform the recited task, and as such would a trivial 
variation of ordinary skill in the art. As such, the rejection for claim 13 is hereby 
incorporated by reference with motivation and combination and is valid without further 
comment. The six components of the SVG standard shapes include an ellipse, a 
rectangle, a line, and a path - see SVG section 9.1. Motivation for combining Itou, Kim, 
and SVG is taken from the rejection to claim 36. Motivation for adding Steele is taken 
from the rejections to claims 4 and 5. 

59. As to claim 44, 

The system of claim 40 wherein the markup is converted to a method call to associate a 
transform with the visual object. 

This claim is a substantial duplicate of claim 3. Further, the term 'geometry' used 
here is analogous to the 'shape' reference in claim 3. The only difference is that the 
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markup is converted to a metliod call to perform the recited action, whereas claim 3 
merely 'invokes code' to perform the recited task, and as such would a trivial variation of 
ordinary skill in the art. As such, the rejection for claim 3 is hereby incorporated by 
reference with motivation and combination and is valid without further comment. The 
six components of the SVG standard shapes include an ellipse, a rectangle, a line, and 
a path - see SVG section 9.1 . Motivation for combining Itou, Kim, and SVG is taken 
from the rejection to claim 36. Motivation for adding Steele is taken from the rejections 
to claims 4 and 5. Further, the teachings of Steele are applicable because SVG is used 
herein to illustrate this point. 
60. As to claim 45, 

The system of claim 44 wherein the transform comprises a rotate transform for 
changing a perceived angle of the visual object. 

This claim is a substantial duplicate of claim 3. Further, the term 'geometry' used 
here is analogous to the 'shape' reference in claim 3. The only difference Is that the 
markup is converted to a method call to perform the recited action, whereas claim 3 
merely 'invokes code' to perform the recited task, and as such would a trivial variation of 
ordinary skill in the art. Specifically, Steele [0053] clearly states that rotations are 
applied to visual objects or groups of visual objects, and states that as well. 

As such, the rejection for claim 3 is hereby incorporated by reference with 
motivation and combination and Is valid without further comment. The six components 
of the SVG standard shapes include an ellipse, a rectangle, a line, and a path - see 
SVG section 9.1 . Motivation for combining Itou, Kim, and SVG is taken from the 
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rejection to claim 36. Motivation for adding Steele is taken from the rejections to claims 
4 and 5. 

61 . As to claim 46, 

The system of claim 44 wherein the transform comprises a scale transform for changing 
a perceived size of the visual object. 

Reference Kim does not expressly teach this limitation, but clearly teaches that 
users navigate through a virtual environment, which prima fade requires that transforms 
take place to visual objects. References Steele and Itou teach this limitation implicitly, 
as he discloses rotations in [0053] and further states that rotations and other 
transfonnations can be applied to an entire tree of objects, e.g. Fig. 7, and further [0088] 
that any visual element or object can modified. Such modifications prima facie must 
associate code with a suitable / desired transfomri (e.g. scaling, rotation, et cetera 
[0053]), as that is the only way either a hierarchy of nodes (e.g. Fig. 7) or single nodes 
could be scaled. Reference Itou discloses rotations and other actions on SVG and XML 
elements in 11:65-57. 

Specifically, however, the SVG specification provides for scaling transformations 
in Example Rotate-Scale in section 7.4 under coordinate system transformations 

As such. It would have been obvious to one having ordinary skill in the art at the 
time the invention was made to combine the SVG and graphics system of Steele and 
Itou with the X3D and graphics system of Kim as set forth above and the SVG 
specification, and because they provide for coordinate transforms as set forth above, 
and the Kim reference inherently performs transforms as a user can navigate through a 
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virtual 3D environment, which inherently requires graphics transforms and such. 
(Please see claim 36 for additional motivation / combination justification, which is herein 
incorporated by reference). (Further, note that since this is performed by software, 
prima facie 'code' that is software elements, would be invoked to perform any recited 
task.) 

62. As to claim 47, 

The system of claim 44 wherein the transfonn comprises a translate transfomi for 
changing a perceived position of the visual object. 

This claim is a substantial duplicate of claim 3. Further, the term 'geometry' used 
here is analogous to the 'shape' reference in claim 3. The only difference is that the 
markup is converted to a method call to perform the recited action, whereas claim 3 
merely 'invokes code' to perform the recited task, and as such would a trivial variation of 
ordinary skill in the art. Specifically, Steele [0053] clearly states that translations are 
applied to visual objects or groups of visual objects, and states that as well. 

As such, the rejection for claim 3 is hereby incorporated by reference with 
motivation and combination and is valid without further comment. The six components 
of the SVG standard shapes include an ellipse, a rectangle, a line, and a path - see 
SVG section 9.1. Motivation for combining Itou, Kim, and SVG is taken from the 
rejection to claim 36. Motivation for adding Steele is taken from the rejections to claims 
4 and 5. 

63. As to claim 48, 
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The system of claim 44 wherein the transform comprises a skew transform for changing 
a perceived skew of the visual object. 

Reference Kim does not expressly teach this limitation, but clearly teaches that 
users navigate through a virtual environment, which prima facie requires that transforms 
take place to visual objects. References Steele, Itou, and SVG teach this implicitly, that 
is Steele teaches it implicitly, this limitation that is, as he discloses rotations in [0053] 
and further states that rotations and other transformations can be applied to an entire 
tree of objects, e.g. Fig. 7, and further [0088] that any visual element or object can 
modified. Such modifications prima facie must assodate code with a suitable / desired 
transform (e.g. scaling, rotation, et cetera [0053]), as that is the only way either a 
hierarchy of nodes (e.g. Fig. 7) or single nodes could be scaled. 

Specifically, however, the SVG specification provides for skew transformations in 
Example Skew in section 7.4 under coordinate system transformations. 

As such. It would have been obvious to one having ordinary skill in the art at the 
time the invention was made to combine the X3D and graphics system of Steele with 
the SVG and graphics system of Kim as set forth above and the SVG specification, and 
because they provide for coordinate transforms as set forth above, and the Kim 
reference inherently performs transforms as a user can navigate through a virtual 3D 
environment, which inherently requires graphics transforms and such. (Please see 
claim 36 for additional motivation / combination justification, which is herein 
incorporated by reference). (Further, note that since this is performed by software, 
prima facie 'code' that is software elements, would be invoked to perform any recited 
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task.) Motivation for combining Itou, Kim, and SVG is tal<en from the rejection to claim 
36. IVIotivation for adding Steele is taken from the rejections to claims 4 and 5. 
64. As to claim 49, 

The system of claim 44 wherein the markup provides animation information associated 
with the transform, and wherein the animation information causes transformation data 
associated with the transfonn to change over time thereby animating the transformation 
of the visual object over time. 

Reference Kim does not expressly teach this limitation, while references Steele, 
Itou, and SVG do teach it. Steele clearly establishes in [0051-0054] and Figs. 6 and 9 
that animation takes place through the SVG standard. Section 19.2 of SVG sets forth 
how this takes place, and at the bottom three paragraphs of section 19.2.2 it clearly 
states that animatiOon has a document start and document end, and further in the 
second to last paragraph that the SVG system indicates the timeline position of 
document fragments being animated. Further, according to SVG 19.2.2 the animation 
is by document fragment and object path, which clearly are passed to the system is 
specified in, for example, the second page of Fig. 9 in the SVG XML program. Clearly, 
the system of Steele performs compositing and rendering [0007, 001 1-0012], as does 
Kim. Finally, reference SVG teaches that it supports compositing (section 14.2.1 ), and 
the X3D specification supports compositing (6.2.3 for example). The composition 
engine would be, for example, elements 143, 144, and 147 of Fig. 2 of Kim. 

Steele in Figs. 6 and 9 shows animated elements [0041] and in Fig. 8, clearly 
during an animation the actions are shown, where the system in steps 835, 840, and 
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846 performs interpolation for nodes shown in the tree In Fig. 7. Clearly interpolation 
takes place during animation [0072, 0077-0079] which performs interpolation during the 
animation process as set forth in the SVG standard, and prima facie the output would 
only be objects in the scene graph, and they would prima facie be based on the timeline 
as set forth above. SVG is a markup language, therefore any SVG rendering utility 
would prima facie receive markup, and any SVG rendering program would prima facie 
invoke such functionality. Motivation for combining Itou, Kim, and SVG is taken from 
the rejection to claim 36. Motivation for adding Steele is taken from the rejections to 
claims 4 and 5. 
65. As to claim 50, 

The system of claim 40 wherein the markup is converted to a method call to associate a 
color with the visual object. 

This claim is a substantial duplicate of claim 7. The only difference is that the 
markup is converted to a method call to perfomri the recited action, whereas claim 3 
merely 'invokes code' to perform the recited task, and as such would a trivial variation of 
ordinary skill in the art. A color as recited here Is applied via the paint method (SVG 
1 1 .1 - 1 1 .4) and Is the exact same as the "solid color" associated with a "brush" as in 
claim 7 - the "brush" is merely a semantic description as set forth above. As such, the 
rejection for claim 7 is hereby incorporated by reference with motivation and 
combination and is valid without further comment. Clearly, SVG teaches the use of a 
solid color with a visual object - see SVG 11.1. Motivation for combining Itou, Kim. and 
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SVG is taken from the rejection to claim 36. Motivation for adding Steele is taken from 
the rejections to claims 4 and 5. 

66. As to claim 51 , 

The system of claim 40 wherein the markup is converted to a method call to associate 
gradient data with the visual object. 

This claim is a substantial duplicate of claim 7. The only difference is that the 
markup is converted to a method call to perform the recited action, whereas claim 3 
merely 'invokes code' to perform the recited task, and as such would a trivial variation of 
ordinary skill in the art. A gradient as recited here is applied via the paint method (SVG 
11.1-11.4) and is the exact same as the "solid color" associated with a "brush" as in 
claim 7 - the "brush" is merely a semantic description as set forth above, and a linear 
gradient is certainly a gradient. As such, the rejection for claim 7 is hereby incorporated 
by reference with motivation and combination and Is valid without further comment. 

S*' 

Clearly, SVG teaches the use of a gradient with a visual object - see SVG 11.1. 
Motivation for combining Itou, Kim, and SVG is taken from the rejection to claim 36. 
Motivation for adding Steele is taken firom the rejections to claims 4 and 5. 

67. As to claim 52, 

The system of claim 40 wherein the markup is converted to a method call to associate a 
tile brush with the visual object. 

Reference Kim does not expressly teach this limitation. Reference Steele does 
teach this limitation by the use of SVG graphics. Turning to the SVG (, section 1 1 titled 
•Painting: Filling, Stroking, and Marker Symbols', specifically section 11.1, 'With SVG, 
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you can paint (e.g. stroke or fill) with: ..." and then proceeds to list several. The term 
'brush data' is clearly analogous to the 'paint' operation in SVG with comparable data. 
Given that SVG allows (from section 11.1), among other things a pattern (vector or 
image) that can be tiled, clearly each visible element clearly has such data associated 
with it (see section 1 1 .2 in its entirety, 1 1 .7 for specific properties, section 1 1 .8 for how 
painting properties can be inherited, which prima facie justifies the position that element 
have intrinsic painting properties, i.e. brush data as set forth above. Further, note that 
since this is perfomried by software, prima facie 'code' that is software elements, would 
be invoked to perform any recited task, and SVG data element prima facie and 
inherently possess paint data as set forth by the SVG specification above. As such, 
reference Steele intrinsically teaches this limitation. Motivation for combining Itou, Kim, 
and SVG is taken from the rejection to claim 36. Motivation for adding Steele is taken 
from the rejections to claims 4 and 5 and the SVG standard inherently handles these 
paint limitations. 
68. As to claim 53, 

The system of claim 40 wherein the markup is converted to a method call to associate 
an image with the visual object. 

This claim is a substantial duplicate of claim 10. The only difference is that the 
markup is converted to a method call to perform the recited action, whereas claim 3 
merely 'invokes code' to perform the recited task, and as such would a trivial variation of 
ordinary skill in the art. An image as recited here is applied via the paint method (SVG 
11 . 1 - 1 1 .4) and is the exact same as the image associated with a "brush" as in claim 7 
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- the "brush" is merely a semantic description as set forth above. As such, the rejection 
for claim 10 is hereby incorporated by reference with motivation and combination and is 
valid without further comment. Clearly, SVG teaches the use of an image with a visual 
object - see SVG 11.1. Motivation for combining Itou, Kim, and SVG is taken from the 
rejection to claim 36. Motivation for adding Steele is taken from the rejections to claims 
4 and 5. 

69. As to claim 54, 

The system of claim 40 wherein the markup is converted to a method call to assodate a 
drawing comprising drawing primitives with the visual object. 

References Kim and Steele do not expressly teach these limitations; references 
Steele and Itou teach them intrinsically as set forth above in claim 40 and reference 
SVG clearly supports this position. The SVG specification sets forth classes of shapes 
in section 9.1, where six shapes are set forth, and they are fundamental drawing 
primitives. Also, in SVG 7.1 1 , the table lists a "primitiveUnits" that stand for numeric 
primitives within elements of the basic classes or elements being referenced. . Further, 
the SVG view in Steele decomposes SVG instructions into scene graphs containing 
basic SVG shapes as above [Steele 0052], where 'Visual Elements' include Shape 
classes. SVG is a markup language, therefore any SVG rendering utility would prima 
facie receive markup. As such, reference Steele intrinsically teaches this limitation. 
Motivation for combining Itou, Kim, and SVG is taken from the rejection to claim 36. 
Motivation for adding Steele is taken from the rejections to claims 4 and 5. 

70. As to claim 55, 
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The system of claim 40 wherein the markup is converted to a method call to associate 
audio and/or video media with the visual object. 

References Kim and Itou do not expressly teach this limitation, v>^ile reference 
Steele does teach it. Steele in Figs. 8 shows audio elements 820 and 830 in the 
animation execution and in Fig. 7 a scene graph data structure (a tree). Steele [0050, 
0052] for example provides that such animation takes place, and the SVG standard in 
6.18 clearly sets forth aural style sheets, that are audio data that each element can 
have animation associated with it, which clearly is placed into the scene graph of Fig. 7. 
Also, by definition, SVG animations would be video. SVG is a markup language, 
therefore any SVG rendering utility would prima facie receive markup, and any SVG 
rendering program would prima facie invoke such functionality. Motivation for 
combining Itou, Kim, and SVG is taken from the rejection to claim 36. Motivation for 
adding Steele is taken from the rejections to claims 4 and 5. 
71. As to claim 56, 

The system of claim 40 wherein the markup is converted to a method call to associate 
an image effect with the visual object. 

This claim is a substantial duplicate of claim 1 1 . The only difference is that the 
markup is converted to a method call to perform the recited action, whereas claim 3 
merely 'invokes code' to perform the recited task, and as such would a trivial variation of 
ordinary skill in the art. An image effect as recited here is applied as set forth in SVG 
section 14.4, with the alpha blending of course being an image effect. As such, the 
rejection for claim 1 1 is hereby incorporated by reference with motivation and 



Application/Control Number: 10/693,633 Page 59 

Art Unit: 2672 

combination and is valid without further comment, as the references are the same. 
Clearly, SVG teaches the use of an image with a visual object - see SVG 14.4. Also, 
the rejection to the parent claim is herein incorporated by reference. 

72. As to claim 57, 

The system of claim 40 wherein the markup is converted to a method call to assodate a 
pen with the visual object, to describe how a shape is outlined. 

This claim is a substantial duplicate of claim 12. The only difference is that the 
markup is converted to a method call to perform the recited action, whereas claim 12 
merely 'Invokes code' to perform the recited task, and as such would a trivial variation of 
ordinary skill in the art. . As such, the rejection for claim 12 is hereby incorporated by 
reference with motivation and combination and is valid without further comment, as the 
references are the same. Clearly, SVG teaches the use of a pen to set outlines - see 
SVG 11.4 and 1 1.5. Motivation for combining Itou, Kim, and SVG is taken from the 
rejection to claim 36. Motivation for adding Steele is taken from the rejections to claims 
4 and 5. 

73. As to claim 58, 

The system of claim 40 wherein the markup is converted to a method call to obtain a 
drawing context associated with the visual object. 

This claim is a substantial duplicate of claim 26. The only difference is that the 
markup is converted to a method to call to perform the recited action, whereas claim 12 
merely makes a 'function call' to perform the recited task, and as such would a trivial 
variation of ordinary skill in the art. As such, the rejection for claim 26 is hereby 
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incorporated by reference with motivation and combination and is valid without further 
comment, as the references are the same. Motivation for combining Itou, Kim, and 
SVG is taken from the rejection to claim 36. Motivation for adding Steele is taken from 
the rejections to claims 4 and 5. 

74. As to claim 59, 

The system of claim 40 wherein the markup is converted to a method call to associate 
hit testing data with the visual object. 

This claim is a substantial duplicate of claim 1 7. The only difference is that the 
markup is converted to a method to call to perform the recited action, whereas claim 17 
merely 'causes data to be modified' to perform the recited task, and as such would a 
trivial variation of ordinary skill in the art. As such, the rejection for claim 17 is hereby 
incorporated by reference with motivation and combination and is valid without further 
comment, as the references are the same. Motivation for combining Itou, Kim, and 
SVG is taken from the rejection to claim 36. Motivation for adding Steele is taken from 
the rejections to claims 4 and 5. 

75. As to claim 60, 

The system of claim 40 wherein the markup is converted to a method call to associate a 
rectangle with the visual object. 

This claim is a substantial duplicate of claim 14. The only difference is that the 
markup is converted to a method to call to perfomi the recited action, whereas claim 14 
merely 'causes data to be modified' to perform the recited task, and as such would a 
trivial variation of ordinary skill in the art. As such, the rejection for claim 14 is hereby 
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incorporated by reference with motivation and combination and is valid without further 
comment, as the references are the same. Also, clearly whether or not the visual 
object is in the scene graph does not matter in the context of this specific claim as it is in 
claim 14. Motivation for combining Itou, Kim, and SVG is taken from the rejection to 
claim 36. Motivation for adding Steele is taken from the rejections to claims 4 and 5. 
76. As to claim 61 , 

The system of claim 61 wherein the markup includes data describing how a source 
rectangle should be stretched to fit a destination rectangle. 

Reference Kim does not expressly teach this limitation, but clearly teaches that 
users navigate through a virtual environment, which prima facie requires that transforms 
take place to visual objects. Reference Steele teaches this implicitly limitation, as he 
discloses rotations in [0053] and further states that rotations and other transfonmations 
can be applied to an entire tree of objects, e.g. Fig. 7, and further [0088] that any visual 
element or object can modified. Such modifications prima facie must associate code 
with a suitable / desired transform (e.g. scaling, rotation, et cetera [0053]), as that is the 
only way either a hierarchy of nodes (e.g. Fig. 7) or single nodes could be scaled. 

Specifically, however, the SVG specification provides for scaling transformations 
in Example Rotate-Scale in section 7.4 under coordinate system transformations. 
Further, SVG clearly teaches the use of rectangles as basic shapes and provides for 
methods for associating one shape with a visual object as set forth in SVG 9.1 . 
Obviously from the parent claim, a rectangle could be scaled using the methods set 
forth in the SVG standard listed immediately above and it would have been obvious to 
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one ordinary sl<ill in the art to so modify the apparatus of Kim in light of Steele and SVG 
as set forth above. 

Motivation for combining Itou, Kim, and SVG is taken from the rejection to claim 
36. Motivation for adding Steele is taken from the rejections to claims 4 and 5. (Please 
see claim 61 for additional motivation / combination justification, v»4iich Is herein 
incorporated by reference). 

Claim 29 is rejected under 35 U.S.C. 103(a) as unpatentable over Kim in View of 
Steele and SVG as applied to claim 28 above, and further in view of X3D (X3D 
specification). 
77. As to claim 29, 

The method of claim 28 wherein causing data in the scene graph to be modified 
comprises mapping a two-dimensional surface onto the three dimensional visual. 

The Kim reference clearly teaches this limitation, and X3D standard is only cited 
to clarify certain points. The Kim reference clearly teaches scene graphs as established 
in the rejection to claim 1 [0007-0009]. Clearly, Kim teaches the use of three- 
dimensional data under the X3D standard specification, which is a form of XML [0007- 
0009]. Clearly, Kim teaches [0032-0034] that scene data is processed and all objects 
have specific sets of data associated with them, for example [0042-0044], which clearly 
establishes that all objects have three-dimensional attributes and properties. This prima 
fade establishes that three-dimensional visuals are placed into the scene graph data 
structure. Clearly, the system implements the X3D specification in software, and, as 
such, it is software, which prima facie uses function calls. Secondly, the X3D standard 
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clearly allows for the incorporation of 2D Images onto three-dimensional elements, as 
stated in X3D 18.2.1 and 18.4.1, particularly 18.4.1, which reads clearly that "browsers 
may support other image formats ... which may be rendered into a 2D image" and 
clearly those images can be applied to three-dimensional objects such as those 
described in 18.3.1 and as defined in 18.2.1-18.2.3. Itou does not expressly teach this 
limitation. No separate motivation is required for the use of the X3D standard, as 
reference Kim explicitly states over 200 times that that standard is the one being used 
and it is central to his invention. Motivation and combination, if required, are adopted 
from the rejection to the parent claim and hereby incorporated via reference. 

Conclusion 

78, Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 
§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply Is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 
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Any inquiry concerning this communication or earlier communications from tlie 
examiner should be directed to Eric V Woods whose telephone number is 571-272- 
7775. The examiner can normally be reached on M-F 7:30-4:30 alternate Fridays off. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Michael Razavi can be reached on 571-272-7664. The fax phone number 
for the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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